When a new automation system or plant is designed, the control application is also developed. Many application components are taken from domain-specific application libraries, for example for oil & gas or the chemical industry. Thus, these components are available from the beginning of the design, but other parts will have to be developed from scratch. The control application and software respectively will be executed on control devices (controllers) which are located within the plant, usually in proximity to the process which is supervised by the control application and/or underlying control algorithm. The number and location of the specified controllers therefore depend on the plant design and the processes being controlled.
A controller includes at least one of a CPU, a data processing unit, computation modules, communication modules for reading sensor data or exchanging data with other controllers, a power supply, interfaces and various accessories. The computation modules and/or processing units for example in most cases are available in different performance levels which relate to the number and complexity of computations they can perform, but more powerful computation modules cause or specify higher technical efforts (design, cooling, environmental conditions or specifications) and higher failure rates in production and finally are more expensive in production as well as in use. Furthermore, it seems to be desirable to have processing units which can be used in a broader variety of control devices.
The respective control application or software as well as the related or underlying algorithms are executed in a cyclic fashion, wherein values are read from I/O devices, the control application and contained control algorithms are executed, and the resulting control parameters are transferred and/or written back to the devices. These operations are activated in predetermined intervals in real-time, for example in the range of about 500 ms, and have to be finished within this timeframe. Thus, the controller hardware has to be chosen in a way that the control algorithms can be executed within the given deadline and for time interval. However, according to complexity and for cost and/or effort reasons it is very desirable to use cheapest and/or simplest computation module and/or processing units which can execute the respective task.
In the automation industry, a control system that controls the behavior of a device, such as a machine, an engine or a drive, or how a process in the process industry should respond to inputs, such as signal inputs, within a specific amount of time, such as in real-time, to ensure a proper operation of said device and/or process.
If one component is present that makes up the response time and accordingly the execution time it can be advisable to determine the software or application worst case execution time, so that the designer/operator of the respective control system can use this information to optimize the system, such as according to its hardware and/or software and at least its operation, to ensure that the system responds fast enough and in real-time.
A real-time system or application in the context of this application can be understood as a system or application which guarantees to respond within strict predeterminable time constraints, time limits, or time frames, also referred to as “deadlines”. Real-time responses can be in the range of milliseconds or microseconds.
Calculating the time a piece or segment of code is going to take to execute has always been a difficult problem. In most cases, it is impossible as it relates to the halting problem which is indeterminable.
In real-time systems, such as real-time control systems in automation industry, calculating the longest time a piece of code might take to execute (Worst-Case Execution time—WCET) on a specific hardware platform, such as specific execution unit like a CPU, which can include a microprocessor or another processing device, can be key to ensuring and providing reliable and/or correct functional behavior or operation of said system.
To get an estimate for the WCET despite its inability to be determined, approximation techniques have to be used or applied, wherein there are two known main approaches to approximate the WCET of a software component or an application component on a specific hardware platform.
The first one relates to the testing or in-situation profiling of a piece of code and use the execution time of diverse executions to calculate the WCET through heuristics and the second one relates to the static analysis of the application code and determining or calculating the WCET using a model or a data structure representing the applied hardware.
The first variant entails that sufficient code coverage can be achieved during the measurements and that the worst-case execution time for every program or application statement has been observed. In practice, these specifications cannot always be fulfilled and therefore the WCET might be under-approximated. For systems with hard real-time specifications, like control systems in automation industry or process industry, this is unsound and potentially unsafe.
Static WCET analysis includes the manual development of a hardware model for the target processor which estimates the execution time based on formal methods. This is a long and costly process. The abstraction underlying the model approximates the execution time in a conservative fashion, thereby leading to an over-approximation of the actual WCET. As the resulting WCET estimate is guaranteed to be an upper bound for every possible execution time of a program or an application, the approach can be safely applied in systems with hard real-time demands.
In automation technology or automation industry there is a slow move and development from well controlled hardware to commodity hardware with many possible execution units, like for example CPU (central processing unit), GPU (global processing unit), FPGA (field programmable gate array), DSP (digital signal processor).
In such systems, the diversity of hardware components and/or configurations makes it impractical and almost impossible to manually develop a new static timing model for every possible target platform or target platform configuration.
Moreover, software or applications for safety critical systems commonly have become very large including a tremendous number of code lines, a few million lines of code, and accordingly too large for exhaustive testing. Thus, it is hazardous to use testing or profiling only, as it is impossible to observe every possible execution of a program to determine the WCET's to provide and ensure a reliable operation of said systems.
Currently, no technical solution is available solving these issues in an efficient way with sufficient quality and minimized technical and/or computational complexity and effort.